chore: add Claude Code safeguards and track CLAUDE.md#30
chore: add Claude Code safeguards and track CLAUDE.md#30mikkeldamsgaard wants to merge 1 commit intomainfrom
Conversation
- Add .claude/settings.json with permission rules: - Deny PR approval/merge/close, force push, push to main/master - Deny destructive commands (rm -rf, sudo, git reset --hard) - Deny editing sensitive paths (~/.ssh, ~/.aws, ~/.gnupg) - Allow non-destructive tools, cargo build/test, git workflow - Allow push --force-with-lease to work branches - Default "ask" mode for anything not explicitly allowed/denied - Track CLAUDE.md and .claude/settings.json in git - Remove CLAUDE.md and .claude/settings.json from .gitignore Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR adds agent safeguards and configuration for Claude Code sessions by introducing two new tracked files: CLAUDE.md (comprehensive AI agent instructions) and .claude/settings.json (permission rules). These files establish operating principles, quality gates, security constraints, and execution rules for AI agents working with this repository.
Changes:
- Added
CLAUDE.mdwith 20 operating principles covering code quality, testing, documentation, security, and change management - Added
.claude/settings.jsonwith layered permission rules (deny/allow/ask modes) for Claude Code sessions - Removed
CLAUDE.mdand.claude/settings.jsonfrom.gitignoreto track them in version control
Reviewed changes
Copilot reviewed 2 out of 3 changed files in this pull request and generated 8 comments.
| File | Description |
|---|---|
| CLAUDE.md | Comprehensive agent instructions covering operating principles, quality gates, robustness, security, change management, and execution constraints |
| .gitignore | Removed entries for CLAUDE.md and .claude/settings.json to enable version tracking |
| .claude/settings.json | Permission configuration with deny rules for dangerous operations, allow rules for safe operations, and default ask mode for everything else |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| - Create a branch with the issue number in the name from origin/main. | ||
| - Implement the issue. | ||
| - Run all e2e tests. | ||
| - If during implementation, obvious errors was found in the ooriginating issue, also add a comment to the issue about the fix. |
There was a problem hiding this comment.
There is a grammatical error. "errors was found" should be "errors were found" for subject-verb agreement.
| - If during implementation, obvious errors was found in the ooriginating issue, also add a comment to the issue about the fix. | |
| - If during implementation, obvious errors were found in the ooriginating issue, also add a comment to the issue about the fix. |
| "Edit(/**)", | ||
| "Write(/**)", |
There was a problem hiding this comment.
The permission rules allow "Edit(/)" and "Write(/)" on lines 49-50, which could potentially allow editing or writing sensitive paths despite the specific deny rules on lines 32-39. Depending on how the permission system evaluates these rules (allow vs deny precedence), this could be a security issue. The broad allow rules may override the specific deny rules for sensitive directories. Consider clarifying the permission evaluation order or making the allow rules more specific to exclude sensitive paths.
| 19) When running locally, prefer the mcp edit tool to direct file edits. | ||
| - If issues arise where files seems unedited, alert the user before continuing | ||
|
|
||
| 20) Prefer bash commands/scripts to python3 when investigating |
There was a problem hiding this comment.
Line 86 is missing a period at the end, which is inconsistent with the formatting of other guideline statements in this document (e.g., lines 84, 81, etc.).
| 20) Prefer bash commands/scripts to python3 when investigating | |
| 20) Prefer bash commands/scripts to python3 when investigating. |
| - Find the issue in github issues. | ||
| - If not found, inform the user. | ||
| - If found: | ||
| - Fetch the git origin |
There was a problem hiding this comment.
The phrase "Fetch the git origin" is unclear. It should be "Fetch from the git origin" or "Fetch from origin" to be more grammatically correct and clear.
| - Fetch the git origin | |
| - Fetch from origin |
| - Avoid making assumptions without asking for confirmation. | ||
|
|
||
| 19) When running locally, prefer the mcp edit tool to direct file edits. | ||
| - If issues arise where files seems unedited, alert the user before continuing |
There was a problem hiding this comment.
This line has two issues: (1) "seems" should be "seem" for subject-verb agreement (files is plural), and (2) it's missing a period at the end, which is inconsistent with the formatting of other guideline statements in this document.
| - If issues arise where files seems unedited, alert the user before continuing | |
| - If issues arise where files seem unedited, alert the user before continuing. |
| "Bash(git push --force-with-lease *)", | ||
| "Bash(git push *)", |
There was a problem hiding this comment.
The permission rules allow "Bash(git push *)" on line 70, which could allow pushing to main/master branches despite the deny rules on lines 11-14. The deny rules use patterns like "Bash(git push * main)" which may not match all variations of push commands to main/master. Consider whether the deny rules are sufficient to block all push attempts to protected branches, or if the allow rule on line 70 should be more restrictive.
| "Bash(git push --force-with-lease *)", | |
| "Bash(git push *)", |
| "Bash(git push --force *)", | ||
| "Bash(git push -f *)", |
There was a problem hiding this comment.
The deny rule "Bash(git push --force *)" on line 15 and "Bash(git push -f *)" on line 16 may not prevent all force push variations. For example, git push --force-with-lease is explicitly allowed on line 69, which is good, but other variations like git push -f --set-upstream origin branch might slip through depending on pattern matching behavior. Additionally, the patterns may not catch git push origin +branch which is another way to force push. Consider whether the deny patterns should be more comprehensive or if the current set is sufficient for the intended security model.
| "Bash(git push --force *)", | |
| "Bash(git push -f *)", | |
| "Bash(git push * --force *)", | |
| "Bash(git push * -f *)", | |
| "Bash(git push * +*)", |
| - Create a branch with the issue number in the name from origin/main. | ||
| - Implement the issue. | ||
| - Run all e2e tests. | ||
| - If during implementation, obvious errors was found in the ooriginating issue, also add a comment to the issue about the fix. |
There was a problem hiding this comment.
There is a typo in "ooriginating" which should be "originating".
| - If during implementation, obvious errors was found in the ooriginating issue, also add a comment to the issue about the fix. | |
| - If during implementation, obvious errors was found in the originating issue, also add a comment to the issue about the fix. |
Summary
.claude/settings.jsonwith layered permission rules enforcing safe defaults for all Claude Code sessionsCLAUDE.md(agent instructions) and.claude/settings.jsonin git so they apply to all collaborators and automated agents.gitignorePermission model
--force-with-leasepush to work branches, make, docker, harmless shell utilitiesHow to verify
🤖 Generated with Claude Code